Redis解决Session共享问题

1.1 基于Session的登录校验

业务流程：

1.2 多服务下Session的共享问题

解决方案：

• Redis 共享：加一层缓存层，将Session存放到Redis中，服务器查询
• JWT：给用户发放JWT令牌，之后请求携带令牌，服务器校验
• Session 广播：某服务器获得 Session 之后，广播给其他服务器，网络开销极大，已淘汰
• IP Hash：使所有来自同一用户的请求访问到同一服务器，某台服务器挂掉，其Session全部失效，容灾能力差

Redis方案和JWT方案对比：

• Redis共享Session：

  核心逻辑： 登录后生成一个随机 Token（如 UUID），用户信息存入 Redis，前端只存 Token。

  ✅ 优点

  • 灵活性极高（主动权在服务端）：
    • 强制下线：管理员可以随时在 Redis 中删掉某个 Token，该用户立刻被踢下线。
    • 多端登录控制：可以轻松实现“同一账号仅限一个设备登录”或“限制登录设备数量”。
    • 实时更新：如果用户权限或头像改了，直接更新 Redis，下次请求立刻生效。
  • 安全性较好：客户端只存一个随机字符串，不包含任何敏感信息，泄露风险相对可控。
  • 数据量小：每次请求 Header 只传一个短 Token，带宽占用极低。

  ❌ 缺点

  • 有状态（依赖外部存储）：服务器必须连接 Redis 才能工作。如果 Redis 挂了，全站无法登录。
  • 网络开销：每次拦截器校验都要走一次 Redis 查询（虽然 Redis 很快，但在超大规模并发下也是压力）。

• JWT令牌：

  核心逻辑： 将用户信息加密、签名后生成一个长字符串直接发给前端。服务器不存任何东西，只靠“秘钥”校验字符串是否被篡改。

  ✅ 优点

  • 真正的无状态（去中心化）：服务器不占内存，也不用查数据库/Redis。只要秘钥对，我就认你。这对跨域和微服务集群非常友好。
  • 性能上限更高：省去了查询 Redis 的网络 IO 耗时，逻辑全在内存中完成（签名校验）。
  • 高可用性：不依赖任何第三方中间件，只要你的 Java 服务跑着，登录校验就不会断。

  ❌ 缺点

  • “泼水难收”（无法主动失效）：
    • 最头疼的问题：一旦 JWT 发出去，除非等到它过期，否则服务端无法撤回。即便用户改了密码或被封号，只要 Token 没过期，他依然能访问。
    • 注：为了解决这个，往往又要引入 Redis 黑名单，结果又回到了 Redis 方案。
  • 数据冗余：JWT 包含了用户信息和签名，字符串很长。如果接口多、并发高，会白白消耗大量带宽。
  • 信息泄露风险：JWT 的 Payload 部分只是 Base64 编码，不是加密。千万不能存密码、手机号等敏感信息，否则谁都能解开看。

• 总结：

  特性	Redis 共享方案	JWT 方案
  数据存储	服务端 (Redis)	客户端 (Browser/App)
  状态维护	有状态	无状态
  主动踢人	支持 (简单)	不支持 (需配合黑名单)
  权限变更	实时生效	需等待 Token 过期
  水平扩展	需配置 Redis 集群	天生支持
  带宽消耗	极低	较高 (Token 较长)

• Redis 方案更重掌控力，适合对安全性和业务逻辑控制要求高的系统；JWT 更重解耦和扩展性，适合轻量级、跨域多或纯无状态的微服务场景。

1.3 基于Redis实现Session共享登录

1.1 业务流程：

1.2 遇到的问题与思考

1.2.1 验证码key的设置问题

我的方案（早期 Token 注入）：

• 流程：发送验证码 -> 生成 Token -> 验证码存 Token 里 -> 返回 Token 给前端 -> 用户输入验证码登录。
• 代价：如果一个恶意攻击者疯狂调用你的“发送验证码”接口，但从来不登录，你的 Redis 里就会充斥着数以万计的 Token 级 Session。每个 Session 还要预留空间准备塞用户信息，这会产生大量的内存碎片和垃圾数据。

他的方案（手机号占位）：

• 流程：发送验证码 -> 手机号做 Key 存验证码 -> 验证成功 -> 生成正式 Token -> 用户信息塞入 Token。
• 优势：
  • 精准打击：验证码阶段只存一个简单的 String（手机号 -> 验证码），占用内存极小。
  • 延迟创建：只有用户真的通过了验证，确定是“自己人”了，才分配昂贵的 Session 资源（Token）。

1.2.2 双拦截器

1. 如果只使用登录拦截器，登录拦截器只会拦截那些需要登录的页面进行校验，给token续期，那些不需要登录的界面，如首页，是不会续期的。这样就出现了一种问题：用户登录之后，看了很久首页，由于登录拦截器没有做拦截，用户被踢下线了，对用户来说体验很不好。
2. 我们可以使用双拦截器，第一道拦截器只负责给有效的token续期，第二道进行对需要登录权限的校验。